Product authentication over a payment network

ABSTRACT

Systems and methods are provided for authenticating a product over a payment network. A product identifier associated with a product to be authenticated may be included or appended to a conventional authorization request message or clearing message during processing of a payment transaction. The product identifier can be verified at a verification entity to determine whether the product is real or counterfeit. Authorization or settlement of the payment transaction can be approved/processed if the product is determined to be real. Authorization or settlement of the payment transaction can be declined/withheld if the product is determined to be counterfeit.

RELATED APPLICATIONS

The present application is a divisional of U.S. patent application Ser.No. 14/500,867 filed on Sep. 29, 2014, the contents of which areincorporated herein by reference in its entirety.

TECHNICAL FIELD

The present disclosure is generally related to electronic transactionprocessing. More particularly, the present disclosure is directed tosystems and methods for integrating product authentication with paymentauthorization and clearing.

BACKGROUND

The use of payment cards for a broad spectrum of cashless transactionshas become ubiquitous in the current economy, accounting for hundreds ofbillions of dollars in transactions during a single year. For example,MasterCard International Incorporated, one example of a payment cardnetwork, processes upwards of 160 million transactions per hour across230 countries. Important aspects involved with the use of payment cardsare the authentication of the payor/consumer using the payment card, aswell as the authorization of the transaction based upon the availabilityof monies in the payor's/consumer's bank.

SUMMARY

In accordance with one embodiment, a method comprises including aproduct identifier in an authorization request message. The methodfurther comprises processing the authorization request message toauthorize a payment transaction and authenticate a product identified bythe product identifier. Further still, the method comprises transmittingan authorization response message approving or declining the paymenttransaction depending upon whether or not the product is authenticated.

In accordance with another embodiment, a non-transitorycomputer-readable medium has computer executable program code embodiedthereon. The computer executable program code is configured to cause acomputer system to authorize payment for an e-commerce transaction.Moreover, the computer executable program code is configured to causethe computer system to include a product identifier in transactioninformation sent to a clearing system that includes e-commerceinformation associated with the e-commerce transaction for which paymentwas authorized. Further still, the computer executable program code isconfigured to cause the computer system to validate the e-commercetransaction information and authenticate the product identifier, andprovide reconciliation based on the validated e-commerce transaction andauthenticated product identifier.

In a further embodiment, a payment network comprises at least oneserver, and at least one memory module storing computer program code,wherein the at least one memory module and stored computer program codeare configured to, with the at least one processor, cause the server to:parse a payment transaction message associated with a paymenttransaction to obtain a product identifier associated with a product tobe purchased; transmit the product identifier to a verification entityfor verification that the product is authentic; upon a determinationthat the product is authentic transmit a payment transaction responsemessage approving the payment transaction; and upon a determination thatthe product is counterfeit, transmit a payment transaction responsemessage declining the payment transaction.

BRIEF DESCRIPTION OF THE DRAWINGS

Further aspects of the present disclosure will be more readilyappreciated upon review of the detailed description of its variousembodiments, described below, when taken in conjunction with theaccompanying drawings.

FIG. 1 illustrates an example payment card transaction processingsystem.

FIG. 2 illustrates an example payment card transaction processing systemover which the authenticity of a product can be verified in accordancewith various embodiments.

FIG. 3 illustrates an example communications system in which variousembodiments may be implemented.

FIG. 4 is a flow chart illustrating various operations that may beperformed to authenticate a product in accordance with one embodiment.

FIG. 5 is a flow chart illustrating various operations that may beperformed to authenticate a product in accordance with anotherembodiment.

FIG. 6 illustrates an example computing module that may be used inimplementing features of various embodiments.

The drawings are described in greater detail in the description andexamples below.

DETAILED DESCRIPTION

The details of some example embodiments of the systems and methods ofthe present disclosure are set forth in the description below. Otherfeatures, objects, and advantages of the disclosure will be apparent toone of skill in the art upon examination of the following description,drawings, examples and claims. It is intended that all such additionalsystems, methods, features, and advantages be included within thisdescription, be within the scope of the present disclosure, and beprotected by the accompanying claims.

Transaction processing of electronic payments can include both anauthorization side and a clearance side. The authorization side mayinvolve the process of confirming that a cardholder has a sufficientline of credit to cover a proposed payment. The clearance side of thetransaction may involve the process of moving funds from an issuing bankto an acquiring merchant bank. FIG. 1 depicts an example payment cardtransaction processing system 100 showing both the authorization sideand the clearance side of card-based payments.

In a typical card-based payment system transaction, a cardholder 102presents a credit/debit/prepaid card 104 to a merchant 106 for thepurchase of goods and/or services. This transaction is indicated byarrow 105. A “card” 104, as used herein, can refer to a conventionalmagnetic-stripe credit, debit card, or similar proximity payment device(utilized on its own or incorporated into another device such as amobile telephone, personal digital assistant (PDA), etc.) having nearfield communications (NFC) capabilities, such as a radio frequencyidentification (RFID) chip implemented therein. A “card” 104 can furtherrefer to virtual or limited use account numbers and electronic wallets.

It is understood that prior to the occurrence of such a transaction,cardholder 102 was issued card 104 by an issuing bank 118. Moreover, itwill be understood that merchant 106 has established a relationship withan acquiring bank 110, thereby allowing merchant 106 to receivecredit/debit cards as payment for goods and/or services. That is,merchant banks and issuing banks may participate in various paymentnetworks, including payment network 112. One such payment network isoperated by MasterCard International Incorporated, the assignee of thepresent disclosure.

After presentation of card 104 to merchant 106 by cardholder 102,merchant 106 may send an authorization request (indicated by arrow 119)to acquiring bank 110 via a point-of sale (POS) terminal 108 located ator otherwise controlled by merchant 106. In turn, acquiring bank 110communicates with payment network 112 (indicated by arrow 121), andpayment network 112 communicates with issuing bank 118 (indicated byarrow 123) to determine whether cardholder 102 is authorized to maketransaction 105. The issuing bank 118 either approves or declines theauthorization request and thereafter transmits the response back tomerchant 106 (indicated by arrows 125, 127 and 129). Merchant 106 maythen either complete or cancel transaction 105 based upon the responseto the authorization request.

If transaction 105 is approved, in accordance with processes calledclearing and settlement, the transaction amount will be sent fromissuing bank 118 through payment network 112 to acquiring bank 110. Thetransaction amount, minus certain fees, will thereafter be depositedwithin a bank account belonging to merchant 106. Issuing bank 118thereafter bills cardholder 102 (indicated by arrow 131) for alltransactions conducted over a given period of time by sending acardholder statement to cardholder 102. Cardholder 102 follows bysubmission of payment(s) (as indicated by arrow 133) to issuing bank118. This submission of payment(s) (as indicated by arrow 133) bycardholder 102 may be automated (e.g., in the case of debittransactions), may be initiated by cardholder 102 for the exact amountmatching amounts of purchases during the statement period (e.g., chargecards or credit balances paid in full), and/or may be submitted (in partor in whole) over a period of time that thereby reflects the amount ofthe purchases, plus any financing charges agreed upon beforehand betweencardholder 102 and issuing bank 118 (e.g., revolving credit balances).

Payment network 112 preferably includes at least one server 114 and atleast one database 116. Server 114 may include various computing devicessuch as a mainframe, personal computer (PC), laptop, workstation or thelike. Server 114 can include a processing device and be configured toimplement an authorization and clearance process, which can be stored incomputer storage associated with server 114. Database 116 may includecomputer readable medium storage technologies such as a floppy drive,hard drive, tape drive, flash drive, optical drive, read-only memory(ROM), random access memory (RAM), and/or the like. Server 114 anddatabase 116 may be controlled by software/hardware and may store datato allow it to operate in accordance with aspects of the presentdisclosure.

POS terminal 108 is in data communication, directly or indirectly, andat least from time to time, with, e.g., an acquirer host computer (notshown) that is part of payment network 112 and is operated for or onbehalf of acquiring bank 110, which handles payment card transactionsfor merchant 106. Server 114 may be operated by or on behalf of thepayment network 112, and may provide central switching and messagerouting functions among the member financial institutions of the paymentcard network. Issuing bank 118 also preferably makes use of an issuerhost computer (not shown), and an access point (not shown) via which theissuer host computer exchanges data messages with server 114. It shouldbe noted that in practice, payment card transaction processing system100 may involve a large number of cardholders, POS terminals, acquirerhost computers, issuer host computers, and access points. In general,the acquirer host computer can receive authorization requests from POSterminals, forward the authorization requests through payment network112, receive authorization responses, and relay the authorizationresponses to POS terminal 108. Moreover, the issuer host computer may ingeneral, receive authorization requests from server 114 and transmitauthorization responses back to server 114 with respect to theauthorization requests.

It should be noted that the terms “authorization” and “authentication”may have distinct definitions in the context of electronic paymenttransactions. For example, the term authorization can refer to (asdescribed above) the process by which issuing bank 118 approves ordeclines a transaction based on the availability of the requisite funds.Authentication can refer to the process of establishing the validity ofcard 104 and/or the account information associated with card 104provided by cardholder 102. Authentication can be accomplished by manualprocesses such as verifying card ownership via physical ID (e.g.,driver's license) and/or by utilizing one or more fraud preventiontools, such as an address verification service (AVS), card securitycodes (CVS)/card verification data (CVD), card verification code (CVC2),and the like. Moreover, merchant 106 may further utilize otherauthentication methods or processes including certain geolocationauthentication mechanisms. In the case of debit payment transactionsreliant upon the use of debit cards, a personal identification number(PIN) can be used for cardholder authentication. In accordance withvarious embodiments, authorization and/or authentication processes canbe considered to be encompassed by the exchange of authorizationinformation (e.g., authorization request and/or authorizationresponses/approval/decline messaging described herein).

Also included in a typical card-based payment system transaction are theclearing and settlement processes alluded to previously and described ingreater detail below.

Clearing (which can happen after transmission of the authorizationresponse if approved) can refer to a process by which issuing bank 118exchanges transaction information with acquiring bank 110 (also referredto as the merchant bank). Referring back to FIG. 1, acquiring bank 110can transmit transaction information to a clearing system 120 (indicatedby arrow 135). Clearing system 120 can validate the transactioninformation, and forward it to acquiring bank 110 (indicated by arrow137), which prepares data to be included on a payment statement forcardholder 102. Clearing system 120 may then provide reconciliation toboth issuing bank 118 and acquiring bank 110 (indicated by arrows 139and 141).

Settlement can refer to a process by which issuing bank 118 exchangesthe requisite funds with acquiring bank 110 to complete an approvedtransaction. In particular, acquiring bank 110 may send clearing data ina clearing message to payment network 112, whereupon payment network 112calculates a net settlement position and sends advisement to acquiringbank 110 and issuing bank 118. Issuing bank 118 can remit payment topayment network 112, which then sends the payment to acquiring bank 110.Acquiring bank 110 then pays merchant 106 for the purchase made bycardholder 102, and issuing bank 118 bills cardholder 102.

As previously alluded to, authentication/authorization procedures areimportant in the context of cashless/electronic payment transactions.For example, and without the ability to verify that a person/entitymaking a payment is authorized to make payment using, e.g., a creditcard, such payment transactions cannot be trusted and the system becomescompromised. The same hold true for ensuring that the person/entity hasthe requisite funds to complete the payment transaction. Moreover, andin an age where the counterfeiting of products (e.g., consumer productssuch as brand name apparel, jewelry, sporting goods, etc.) hasunfortunately become commonplace, consumers need protective measures toavoid being deceived by unscrupulous vendors/manufacturers.

The above is especially true where the authenticity of a product/serviceis of critical importance as is the case with pharmaceutical products,drugs, medicine, etc. For example, some estimates indicate that thecounterfeit trade results in approximately 75 billion dollars per yearof revenue for those that trade in phony drugs. Additionally, the WorldHealth Organization has opined that out of all the packets of medicinesold in street markets in developing countries, approximately 30 percentare counterfeit. The ramifications of the sale of such counterfeitpharmaceuticals is even more disturbing in that up to 2,000 people dieeach day due to the use of substandard or fake drugs.

In an attempt to address these issues, certain systems have beendeveloped to allow for the authentication of pharmaceuticals. One suchsystem is mPedigree. The mPedigree system relies on drug manufacturersworking in conjunction with mPedigree by uploading identifyinginformation from, e.g., each packet of medicine, to a central registry.Using mass serialization methods, the central registry can track arecord of possession from the manufacturer through to variouswholesalers, pharmacies, and ultimately to the end consumer or patient.Each packet of medicine associated with mPedigree may have some uniqueindicia printed on the packet packaging (such as a scratch surface witha hidden 12-digit numerical identifier). Upon purchasing the packet ofmedicine, the consumer may reveal the 12-digit numerical identifier andsend a free short messaging service (SMS) message to query the centralregistry to determine whether or not that 12-digit numerical identifierexists in the central registry. If so, a return SMS message may be sentto the consumer letting the consumer know that he/she can be relativelycertain that the packet of medicine is authentic.

However, certain deficiencies still exist with such systems. Forexample, the security associated with SMS messages may be minimal.Therefore, SMS messages may still be vulnerable to being intercepted,spoofed, or otherwise comprised. That is, a manufacturer of counterfeitpharmaceuticals may be able to produce packaging with fake indicia,intercept an SMS authentication request message sent by the consumerincluding the fake indicia prior to reaching the central (mPedigreerepository), and send a false confirmation SMS message replying to theSMS authentication request message.

Moreover, the use of such an authentication system relies on a paymenttransaction for the pharmaceutical product to be completed. That is, inorder for a consumer or patient to receive the pharmaceutical productand have the ability to reveal the hidden 12-digital numericalidentifier to confirm authenticity, payment has presumably already beenmade to a vendor (whether by cash or by some form of electronicpayment). Hence, any realization that the already purchasedpharmaceutical product is counterfeit relies on the ability of theconsumer or patient to retroactively seek a refund and/or thewillingness of the vendor to provide such a refund. Moreover, andbesides the potential monetary loss, enforcement and/or regulatoryactions against “fly-by-night” operations may be delayed ornear-impossible once the payment transaction has been completed and thecounterfeit drug dealer(s) has fled/moved operations.

Hence, systems and methods are provided for integrating productauthentication with electronic payment authorization/authentication. Inaccordance with various embodiments, product authentication indicia,such as, for example, a numeric or alpha-numeric identifier,quick-response (QR) code, stock keeping unit (SKU), universal productcode (UPC), a manufacturer part number (MPN), a European article number(EAN), or an international standard book number (ISBN), or somecombination thereof, can be included, embedded, or otherwise integratedinto a payment authorization/authentication message that is generallysent with authorizing an electronic payment transaction. In this way,the process of product authentication can be streamlined. Furthermore,the increased security associated with payment transaction authorizationprocedures can serve to also make the product authentication proceduremore secure. Further still, the payment transaction can behalted/declined in the event that the product cannot be properlyauthenticated, thereby avoiding any potential loss of funds for acounterfeit product and/or provide the ability for anyenforcement/regulator/reporting agency to effect action against acounterfeit dealer/manufacturer much sooner.

FIG. 2 illustrates an example payment card transaction processing system200 in which product authentication may be integrated in accordance withvarious embodiments. Elements of system 200 may be considered to be thesame or similar to like-numbered elements of FIG. 1, e.g., cardholder102, card 104, merchant 106, POS 108, acquiring bank 110, paymentnetwork 112 (and its example constituent elements), and issuing bank118. In addition to these elements, system 200 may further include averification entity, such as central repository 122, with which productauthentication may be verified. Central repository 122 may include oneor more servers, processors, and/or databases that can receive, e.g.,product indicia, and match that product indicia with previously storedproduct indicia (if existent) therein.

Additionally, system 200 may include connectivity to a third-party 124,such as a product manufacturer, distributor, and the like. Suchconnectivity between payment network 112 and third-party 124 can allowpayment network 112 to, e.g., notify third-party 124 when and/or where acounterfeit product has been discovered as being sold to aconsumer/patient. Third-party 124 may also be communicatively connectedto central repository 122, where central repository 122 may assume thetask of notifying third-party 124 when/where a counterfeit product hasbeen discovered. The aforementioned integration of productauthentication with payment authorization, as well as such notificationcan occur in real-time or near-real-time. In accordance with otherembodiments, such as may be the case in e-commerce payment transactions(e.g., web-based online purchases), some delay can be introduced, but ineither scenario, combating the sale of counterfeit products andenforcement actions regarding the sale of counterfeit products can beinitiated and/or performed much sooner than in conventional systems.

As described above, product indicia may be embedded or otherwiseincluded in a payment authorization message to effect productauthentication. In accordance with one embodiment, a product identifier,such as a unique serial number, SKU, UPC, or other identifyinginformation can be added to payment transaction data as part of acashless or electronic payment transaction. For example, and in a retailsetting, the product identifier can be added to data that isconventionally gathered, e.g., an account number associated with card104, an identification number of merchant 106/POS terminal 108, atransaction amount, etc. That is, a retail clerk at merchant 106 maymanually enter the product identifier as another piece of transactiondata.

In accordance with another embodiment, and in the event card 104 is,e.g., a debit card, cardholder 102 in possession of card 104 may enterthe product identifier in addition to the entry of a PIN associated withcard 104. Alternatively still, an application such as an interactivegraphical user interface (GUI) may be displayed to cardholder 102 at POSterminal 108 that allows cardholder 102 to enter the product identifier.The interactive GUI may be added to the hardware and/or software used toimplement POS terminal 108. For example, certain POS devices atpharmacies may already utilize an interactive GUI that, e.g., captures aconsumer's signature or other identifying information in order toauthorize the purchase of certain pharmaceutical products, such as thosecontaining pseudoephedrine. Capturing of the product identifier can beadded as another aspect of such an interactive GUI.

Other embodiments may utilize a mobile device payment application, suchas that which can be implemented as a payment application on a tabletPC, a smart phone, or similar device. That is, the mobile device may actas a POS terminal. Accordingly, the mobile device payment applicationmay include a mechanism, such as an interactive GUI that in addition tocapturing conventional transaction data, may also allow for the entry ofa product identifier of a product to be authenticated. For example,cardholder 102 may initiate and/or log on to such a mobile devicepayment application. Thereafter, cardholder 102 may enter the productidentifier as well as, e.g., an identification number or code associatedwith merchant 106 to effectuate authentication of the product as well aspayment to merchant 106. Cardholder 102 may have card 104 pre-associatedwith the mobile device payment application, and the identificationnumber or code associated with merchant 106 can allow for payment withcard 104 via the mobile device payment application.

In particular, and once the product identifier is included in or withthe transaction data, that product identifier may be transmitted throughsystem 200 in an authorization message as previously described. That is,and after presentation of card 104 to merchant 106 by cardholder 102,merchant 106 may send an authorization request including the productidentifier and transaction data (indicated by arrow 119) to acquiringbank 110 via POS terminal 108 located at or otherwise controlled bymerchant 106. In turn, acquiring bank 110 communicates with paymentnetwork 112 (indicated by arrow 121). Payment network 112 can parse theauthorization message to obtain the included product identifier. Paymentnetwork 112, using, e.g., an application programming interface (API),can make a call to central repository 122 to obtain authentication of aproduct associated with the product identifier (indicated by arrow 121a). It should be noted that although FIG. 2 represents a single centralrepository 122 (there can be multiple repositories that payment network112 can access, e.g., for different types of products). Additionally,such a repository need not be centralized but can be embodied as adistributed system/network of repositories, or a hybrid combination of acentralized and distributed repository.

If the product identifier is deemed to be an invalid product identifier,e.g., the product identifier cannot be matched or associated with avalid product identifier stored in central repository 122, centralrepository 122 can indicate this determination to payment network 112(indicated by arrow 122 a). Payment network 112 can then adjust theauthorization response. That is, payment network 122 can indicate toissuing bank 118 that the product is determined/believed to becounterfeit. This can be done in a separate message (indicated by arrow123 a) or as part of the communication with issuing bank 118 (indicatedby arrow 123) to determine whether cardholder 102 is authorized to maketransaction 105. Issuing bank 118 can then decline the authorizationrequest and thereafter transmit the response back to merchant 106(indicated by arrows 125, 127 and 129). Alternatively, payment network112 can wait for issuing bank 118 to disprove the authorization requestbased on, e.g., available funds/cardholder 102 authentication. Paymentnetwork 112 may then add an indication regarding the additional basisfor declining the authorization request (i.e., inability to authenticatethe product) in the messaging back to merchant 106 (indicated by arrows127 and 129) or with additional messaging (127 a/129 a). Merchant 106may then cancel transaction 105 based upon the response to theauthorization request. If it is deemed that the product is valid,messaging indicating this can be transmitted/exchanged between theelements of system 200 in a manner similar to that/the same as thatdescribed above, where merchant 106 can ultimately complete transaction105.

In accordance with another embodiment, it can be issuing bank 118 thatmakes the determination to approve/decline the transaction. That is,issuing bank 118 can receive a message/indication (indicated by arrow122 a) from central repository 122 that the transaction should beapproved/declined based on whether or not the product identified by theproduct identifier used by payment network 112 to query centralrepository 122 was authenticated. Issuing bank 118 may thenapprove/decline the authorization request as part of the “standard”approval/decline message 125 to payment network 112 or via aseparate/additional message 125 a.

As described above, certain delays may be encountered in an e-commercescenario. Accordingly, product authentication can be integrated into theclearing process, rather than the authorization process in accordancewith some embodiments. That is, and in e-commerce scenarios, there canbe a delay in the transaction, e.g., between purchase order submissionby cardholder 102 and obtaining the ordered product/shipping the orderedproduct. Hence, seeking authentication of a product duringcard/cardholder authorization would be ineffective because cardholder102 will not yet have the product. Thus, in an e-commerce scenario,conventional authorization to verify available funds and/or the propercardholder can be performed. Thereafter, and once a product isobtained/ready for shipment, merchant 106 may authenticate the productby embedding/appending a product identifier in the transactioninformation sent in a clearing record (e.g., when acquiring bank 110transmits transaction information to payment network 112). In this way,the product can be authenticated (in the same or similar manner as thatdescribed above in a non-e-commerce scenario), but it is clearing system120 of payment network 112 that can parse the product identifier fromthe transaction information/clearing record and authenticate the productvia central repository 122. Then, if the product is authenticated, theproduct can be shipped and settlement can be initiated with thetransmission of the clearing data in a clearing message from acquiringbank 110 to payment network 112. If the product is not authenticated,the clearing message can be withheld, and the appropriatenotification/messaging can be transmitted/exchanged, and subsequentactions for handling counterfeit product transactions (some of whichhave already been discussed above) can be performed.

It should be noted that payment network 112 may communicate withthird-party 124 regarding when counterfeit products are identified(indicated by arrow 124 a). Such communications may include individualinstances of counterfeit product determination and/or collected reports,statistics, or similar information. In addition to indicating whencounterfeit products have been identified, payment network 112 cannotify third-party 124 about where/what merchant was involved in theattempted sale of counterfeit products. Such information can be gleanedfrom merchant identification numbers/codes/data that may be transmittedin transaction data (as described above). Alternatively, or in additionto payment network 112 communicating with third-party 124, centralrepository 122 may also communicate with third-party 124 (indicated byarrow 124 b) regarding the discovery of counterfeit products.

In the case of mobile device payment scenarios, the aforementionedmobile device payment application may be able to glean, e.g.,geo-location information, or other merchant identifying information,regarding a merchant. FIG. 3 is a block diagram illustrating anexemplary communication system in which various embodiments may beimplemented in accordance with the present disclosure. Referring to FIG.3, a communications system 300 which includes a plurality of mobiledevices, of which mobile devices 302-308 is illustrated. One or more ofmobile devices 302-308 can include the aforementioned mobile devicepayment application for effecting electronic/cashless paymenttransactions and product authentication according to various embodimentsdescribed in the present disclosure. Example mobile devices may includea smart phone 302, a cellular device 304, a personal digital assistant(PDA) 306, and/or a tablet PC 308. Also shown in communication system300 is a mobile core network 310, a wireless access point (AP) 312, acellular base station (BS) 314, a Bluetooth® emitter 316, a Near FieldCommunication (NFC) terminal 318, a global navigation satellite system(GNSS) network 320, a plurality of GNSS satellites 322 a-322 n, aninternet 330, a location server 340, and a satellite reference network(SRN) 350. One or more of mobile core network 310, wireless AP 312,cellular BS 314, Bluetooth® emitter 316, NFC terminal 318, GNSS network320, GNSS satellites 322 a-322 n, internet 330, location server 340,and/or satellite reference network (SRN) 350 can be used in assisting todetermine the location of one or more of the mobile devices 302-308 foruse in the application and/or to provide communications links to themobile devices 302-308 for allowing mobile devices 302-308 tocommunicate as described herein with respect to product authenticationand payment transaction processing.

Wireless AP 312 may include suitable logic, circuitry, interfaces,and/or code that are operable to provide data services to communicationdevices, such as one or more of the mobile devices 302-308, in adherencewith one or more wireless LAN (WLAN) standards such as, for example,IEEE 802.11, 802.11a, 802.11b, 802.11d, 802.11e, 802.11n, 802.11 ac,802.11v, and/or 802.11u. Wireless AP 312 may communicate with mobilecore network 310 and/or internet 330, via one or more links and/orassociated devices for example. In this manner, wireless AP 312 mayprovide network access to mobile devices 302-308.

Cellular BS 314 may include suitable logic, circuitry, interfaces,and/or code that are operable to provide voice and/or data services tocommunication devices, such as one or more of the mobile devices302-308, in adherence with one or more cellular communication standards.Exemplary cellular communication standards may include Global System forMobile communications (GSM), General Packet Radio Services (GPRS),Universal Mobile Telecommunications System (UMTS), Enhanced Data ratesfor GSM Evolution (EDGE), Enhanced GPRS (EGPRS), and/or 3GPP Long TermEvolution (LTE). Cellular BS 314 may communicate with mobile corenetwork 310 and/or internet 330, via one or more backhaul links and/orassociated devices for example. In this manner, cellular BS 314 mayprovide network access to mobile devices 302-308, enabling a mobiledevice running a mobile device payment application, such as smart phone302, to communicate with one or more databases, services, servers, etc.as described herein.

Bluetooth® emitter 316 may include suitable logic, circuitry,interfaces, and/or code that are operable to provide Bluetooth® basedconnectivity to communication devices, such as one or more of mobiledevices 302-308, in adherence with various Bluetooth® and/or Bluetooth®Low Energy (BLE) standards. Bluetooth® emitter 316 may communicate withmobile core network 310 and/or internet 330, via one or more backhaullinks and/or associated devices for example. In this manner, Bluetooth®emitter 316 may provide network access to mobile devices 302-308,enabling a mobile device running a mobile device payment application,such as smart phone 302 to communicate with, e.g., merchant 106/POSterminal 108.

NFC terminal 318 may include suitable logic, circuitry, interfaces,and/or code that can provide NFC-based connectivity to communicationdevices, such as one or more of the mobile devices 302-308, in adherencewith various short range communication standards such as the Near FieldCommunications standards. The NFC terminal 318 may communicate with themobile core network 310 and/or the internet 330, via one or morebackhaul links and/or associated devices for example. In this manner,the NFC terminal 318 may provide network access to the mobile devices302-308. One example implementation of an NFC terminal 318 is for use ina contactless payment system and/or for communicating with, e.g.,merchant 106/POS terminal 108.

Mobile core network 310 may include suitable logic, circuitry,interfaces, and/or code that are operable to provide interfacing and/orconnectivity servicing between access networks, which may be utilized bythe mobile devices 302-308, and external data networks such as packetdata networks (PDNs) and/or internet 330. Mobile core network 310 maycorrespond to one or more service providers that provide, control,and/or manage network accessibility available via mobile devices302-308. In this regard, mobile devices 302-308 may access the mobilecore network 310 via wireless AP 312, cellular BS 314, Bluetooth®emitter 316, and/or NFC terminal 318. Mobile core network 310 maycommunicate various data services, which are provided by external datanetworks, to associated user devices such as, for example, mobiledevices 302-308. In an example aspect of the disclosure, in instanceswhere a mobile device payment application is provided to a user devicesuch as smart phone 302, mobile core network 310 may be operable tocommunicate with location server 340 to obtain location information thatcan be used by the mobile device payment application to, e.g., ascertaina location of merchant 106.

Each of mobile devices 302-308 may include suitable logic, circuitry,interfaces, and/or code for implementing various aspects of theembodiments disclosed herein. In this regard, each of mobile devices302-308 may be operable to communicate via a plurality of wired and/orwireless connections. Each of mobile devices 302-308 may be operable,for example, to transmit to and/or receive signals from one or more ofwireless AP 312, cellular BS 314, Bluetooth® emitter 316, NFC terminal318, GNSS network 320, and/or internet 330. Also, each of mobile devices302-308 may be operable to communicate with, and/or receive servicesprovided by internet 330 and/or mobile core network 310. In this regard,mobile devices 302-308 may be operable to utilize mobile device paymentapplications, which can utilize location server 340.

GNSS network 320 may include suitable logic, circuitry, interfaces,and/or code that may provide navigation information to land-baseddevices via satellite links. In this regard, GNSS network 320 mayinclude, for example, a plurality of GNSS satellites 322 a-322 n, eachof which is operable to provide satellite transmissions based on a GNSS.Exemplary GNSS systems may include, for example, GPS, GLONASS,Galileo-based satellite system, Beidou and/or Compass systems.Accordingly, GNSS network 320 may be operable to provide positioninginformation via downlink satellite links transmitted from one or more ofthe plurality of GNSS satellites 322 a-322 n to enable land-baseddevices, such as the mobile devices 302-308, to determine theirlocations. The plurality of GNSS satellites 322 a-322 n may directlyprovide positioning information and/or a land-based device may utilizesatellite transmissions from different satellites to determine itslocation using, for example, triangulation based techniques.

SRN 350 may include suitable logic, circuitry, interfaces, and/or codethat are operable to collect and/or distribute data for GNSS satelliteson a continuous basis. SRN 350 may include a plurality of GNSS referencetracking stations located around the world to provide A-GNSS coverageall the time in both a home network and/or any visited network. In thisregard, SRN 350 may utilize satellite signals received from various GNSSconstellations, such as, for example, the plurality of GNSS satellites322 a-322 n of GNSS network 320.

Location server 340 may include suitable logic, circuitry, interfaces,and/or code that are operable to provide and/or support location basedservices. In this regard, location server 340 may be operable to storeand/or process location related information pertaining to communicationdevices in system 300, such as one or more of mobile devices 302-308.The location information may be stored in a location reference database342 in location server 340. Location server 340 may be operable tocollect and/or retrieve location information from communication devices.Location server 340 may also be operable to access additional and/ordedicated entities, such as SRN 350 for example, to collect GNSSsatellite data, and may be operable to utilize the collected GNSSsatellite data to generate GNSS assistance data (A-GNSS data) including,for example, ephemeris data, long term orbit (LTO) data, referencepositions and/or time information. Location server 340 may communicatethe stored location data when requested to do so.

In operation, location server 340 may be utilized to provide locationbased services (LBS) in system 300. Location server 340 may maintain,for example, location reference database 342, which may include elementscorresponding to each of mobile devices 302-308. Location server 340 mayaccess SRN 350 to collect GNSS satellite data, and may utilize thecollected GNSS satellite data to generate GNSS assistance data (A-GNSSdata) pertaining to the mobile devices 302-308. Location server 340 mayalso collect and/or retrieve location information directly from mobiledevices 302-308, and/or from other associated entities that interactwith mobile devices 302-308 in system 300, such as, for example,wireless AP 312, cellular BS 314, Bluetooth® emitter 316, and/or NFCterminal 318. The retrieved location information may be stored inlocation reference database 342 in location server 340. Location server340 may communicate the stored location data, e.g., when requested to doso. Location reference database 342, maintained in location server 340,may be modified, refined, and/or updated using retrieved locationinformation. Location information stored and/or maintained by locationserver 340 may be utilized to augment and/or substitute for locationinformation received and/or generated based on communication with GNSSnetwork 320, for example, when communication with GNSS network 320 isdisturbed.

The location data may also be locally generated, and/or maintainedthereafter by devices and/or entities other than location server 340. Inthis regard, location related data, which typically may be generatedand/or maintained by location server 340, may be locally generated,maintained, and/or used by mobile devices 302-308, and/or by serviceproviders thereof. Accordingly, devices and/or entities that typicallymay be serviced by location server 340, such as mobile devices 302-308,may also perform location related servicing locally. Furthermore,locally generated and/or maintained location related data may beuploaded from mobile devices 302-308, and/or service providers thereof,to location server 340. Uploading the location related data may beperformed periodically, on request, and/or based on the configuration ofthe client devices or entities, and/or location server 340 itself.

The location information stored and/or maintained in location server 340may be utilized to authenticate, for example, one or more of mobiledevices 302-308, users thereof, and/or locations thereof duringoperations performed by mobile devices 302-308. In this regard, serviceproviders, who may provide access servicing to mobile devices 302-308,may contact location server 340 to request that location server 340perform authentication procedures, and/or to obtain informationnecessary for performing the authentication procedures. The serviceproviders may include, for example, cellular, Bluetooth®, WLAN, and/orNFC services providers. For example, a service provider of one of mobiledevices 302-308 may request authenticating the mobile device, its user,and location at a given instance. Location server 340 may then performthe necessary authentication procedures, which may be based on existinginformation in location reference database 342, which is maintained bylocation server 340. Location server 340 may also perform authenticationprocedures based on current information, which may be obtained by, forexample, communicating with the mobile device, to verify its presentlocation and/or connectivity status or parameters. In this regard,location server 340 may communicate with the mobile device using IPpackets that may be communicated via internet 330, which may betransmitted to and/or received by the mobile device via its internetconnectivity, and/or via its network access via wireless AP 312,cellular BS 314, Bluetooth® emitter 316, and/or NFC terminal 318.

Internet 330 may include a system of interconnected networks and/ordevices that enable exchange of information and/or data among aplurality of nodes, based on one or more networking standards,including, for example, Internet Protocol (IP). Internet 330 may enable,for example, connectivity among a plurality of private and public,academic, business, and/or government nodes and/or networks, wherein thephysical connectivity may be provided via the Public Switched TelephoneNetwork (PSTN), utilizing copper wires, fiber-optic cables, wirelessinterfaces, and/or other standards-based interfaces.

Various devices and/or user identification information may be utilizedduring network access and/or communications, which may be structured,allocated, and/or assigned based on the specific wired and/or wirelessprotocols that are used to facilitate any such network access and/orcommunication. For example, in GSM and/or WCDMA based networks,International Mobile Equipment Identity (IMEI) parameters may beutilized to uniquely identify mobiles devices, and these IMEI parametersmay also be used and/or traced back to the mobile devices' users.Service providers may utilize the device and/or user identificationinformation to track mobile devices and/or users. The service providersmay track devices and/or users for various reasons, including, forexample, billing or usage monitoring, and/or to help locate mobiledevices, and/or their users, in cases of emergency and/or lawenforcement purposes. Tracking of devices may also be used to provideauthorized LBS and/or real-time device location information which can beutilized by mobile device payment applications, such as exemplaryembodiments of the mobile device payment application according to thepresent disclosure, running on the mobile device or other devices and/orsystems.

Conventional payment transactions can be premised on InternationalOrganization for Standardization (ISO) 8583, which defines a messageformat and communication flow for payment transactions (i.e., financialtransaction card originated messages) in electronic fund transfers at aPOS terminal. For example, MasterCard bases authorization communicationson ISO 8583. Because ISO 8583 defines system-to-system messaging forsecure key exchanges, messaging may be considered secure and appropriatefor transmitting a product identifier. Although various embodiments maybe herein described in the context of utilizing the ISO 8583 messagingformat, other formats whether known or developed and implementedspecifically to address product authentication over a payment network,can be utilized.

An ISO 8583 message can be made of the following parts: a message typeindicator (MTI); one or more bitmaps indicating which data elements arepresent; and data elements, i.e., the fields of the message.Accordingly, a new message type can be defined to include a productidentifier in addition to conventional transaction data in anauthorization message and/or clearing message. Alternatively, a productidentifier can be appended to one or more existing/currently defineddata fields in an authorization or clearing message. Returning to FIG.2, an entire authorization or clearing message can be sent to centralrepository 122, where central repository 122 can parse the authorizationor clearing message to obtain the data field having the productidentifier for authentication. Alternatively, payment network112/clearing system 120 can parse the authorization/clearing message inorder to extract the product identifier for authentication at centralrepository 122. It should be noted that in the event that the productidentifier is different from, e.g., a UPC or SKU-level code, such UPC orSKU information could be included in the transaction data in accordancewith certain conventional payment transactions. However, and from aprivacy perspective, some embodiments may strip or prevent thetransmittal of UPC, SKU, or other information that could link aconsumer/patient to the use of certain products. Accordingly, in someembodiments, only the product identifier is included in the transactiondata/information to protect consumer privacy with regard to, e.g.,pharmaceutical or other sensitive purchases.

FIG. 4 illustrates a flow chart describing various processes that can beperformed in order to authenticate a product in a payment processingnetwork in accordance with one embodiment. At operation 400, a productidentifier is included in an authorization request message. As describedabove, the product identifier may be received, depending on whatperspective is being considered, at a POS terminal, a mobile devicepayment application, an acquiring bank 110, and/or a payment network112. The product identifier can be received pursuant to the initiationof a payment transaction process and/or during processing of a paymenttransaction. Inclusion of the product identifier can be achieved byappending the product identifier in an authorization request message aspart of a conventional authorization request message, for example, byway of a newly defined data field or as part of an existing data field.At operation 402, the authorization request message is processed toauthorize a payment transaction and to authenticate a product identifiedby the product identifier. That is, and during payment/cardholderauthorization/authentication, the product identifier may be determinedby, e.g., parsing the authorization request message, and transmittingthe product identifier to a verification entity, such as centralrepository 122, to determine if the product is authentic. At operation404, an authorization response message is transmitted, the authorizationresponse message approving or declining the payment transactiondepending upon whether or not the product is authenticated.

FIG. 5 illustrates a flow chart describing various processes that can beperformed in order to authenticate a product in a payment processingnetwork in accordance with another embodiment. For example, and in ane-commerce scenario, at operation 500, payment for an e-commercetransaction is authorized. Once a product is obtained/ready to beshipped upon authorization of the e-commerce transaction, at operation502, a product identifier is included in an e-commerce clearing recordsent to a clearing system that includes e-commerce informationassociated with the e-commerce transaction corresponding to an approvedauthorization record. As described above, it may be a clearing system ofa payment network that verifies whether a product associated with theproduct identifier is real or counterfeit. At operation 504, thee-commerce clearing record is validated and the product identifier isauthenticated. At operation 506, reconciliation for the e-commercetransaction is provided based on the validated e-commerce clearingrecord and the authenticated product identifier. Thereafter, the productcan be shipped and settlement can be initiated with the transmission ofthe clearing data in a clearing message from an acquiring bank to thepayment network.

FIG. 6 illustrates an example computing module 600, an example of whichmay be a processor/controller resident on a mobile device or POSterminal, or a processor/controller used to operate a paymenttransaction device, that may be used to implement various featuresand/or functionality of the systems and methods disclosed in the presentdisclosure.

As used herein, the term module might describe a given unit offunctionality that can be performed in accordance with one or moreembodiments of the present application. As used herein, a module mightbe implemented utilizing any form of hardware, software, or acombination thereof. For example, one or more processors, controllers,ASICs, PLAs, PALs, CPLDs, FPGAs, logical components, software routinesor other mechanisms might be implemented to make up a module. Inimplementation, the various modules described herein might beimplemented as discrete modules or the functions and features describedcan be shared in part or in total among one or more modules. In otherwords, as would be apparent to one of ordinary skill in the art afterreading this description, the various features and functionalitydescribed herein may be implemented in any given application and can beimplemented in one or more separate or shared modules in variouscombinations and permutations. Even though various features or elementsof functionality may be individually described or claimed as separatemodules, one of ordinary skill in the art will understand that thesefeatures and functionality can be shared among one or more commonsoftware and hardware elements, and such description shall not requireor imply that separate hardware or software components are used toimplement such features or functionality.

Where components or modules of the application are implemented in wholeor in part using software, in one embodiment, these software elementscan be implemented to operate with a computing or processing modulecapable of carrying out the functionality described with respectthereto. One such example computing module is shown in FIG. 5. Variousembodiments are described in terms of this example-computing module 500.After reading this description, it will become apparent to a personskilled in the relevant art how to implement the application using othercomputing modules or architectures.

Conventional methods of determining a ticker symbol would generallyrequire the consumer to “manually” perform a variety of searches fromoftentimes, disparate sources of information. Additionally, obtaininginvestment or financial information related to a company often may alsoinvolve engaging in investigative searching using multiple datarepositories and/or accessing a plurality of services in order todetermine whether or not investing in a particular company would bedesirable to the consumer. In contrast, various embodiments allow, e.g.,a consumer, to identify a product of interest, and automatically receivea ticker symbol for a company or corporate entity associated with theproduct of interest of the company or corporate entity is publiclytraded on a stock exchange. Using the received ticker symbol, theconsumer may quickly and efficiently engage in one or more investment orinvestment-related activities.

Referring now to FIG. 6, computing module 600 may represent, forexample, computing or processing capabilities found within desktop,laptop, notebook, and tablet computers; hand-held computing devices(tablets, PDA's, smart phones, cell phones, palmtops, etc.); mainframes,supercomputers, workstations or servers; or any other type ofspecial-purpose or general-purpose computing devices as may be desirableor appropriate for a given application or environment. Computing module600 might also represent computing capabilities embedded within orotherwise available to a given device. For example, a computing modulemight be found in other electronic devices such as, for example, digitalcameras, navigation systems, cellular telephones, portable computingdevices, modems, routers, WAPs, terminals and other electronic devicesthat might include some form of processing capability.

Computing module 600 might include, for example, one or more processors,controllers, control modules, or other processing devices, such as aprocessor 604. Processor 604 might be implemented using ageneral-purpose or special-purpose processing engine such as, forexample, a microprocessor, controller, or other control logic. In theillustrated example, processor 604 is connected to a bus 602, althoughany communication medium can be used to facilitate interaction withother components of computing module 600 or to communicate externally.

Computing module 600 might also include one or more memory modules,simply referred to herein as main memory 608. For example, preferablyrandom access memory (RAM) or other dynamic memory might be used forstoring information and instructions to be executed by processor 604.Main memory 608 might also be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by processor 604. Computing module 600 might likewise include aread only memory (“ROM”) or other static storage device coupled to bus602 for storing static information and instructions for processor 604.

The computing module 600 might also include one or more various forms ofinformation storage devices 610, which might include, for example, amedia drive 612 and a storage unit interface 620. The media drive 612might include a drive or other mechanism to support fixed or removablestorage media 614. For example, a hard disk drive, a floppy disk drive,a magnetic tape drive, an optical disk drive, a CD or DVD drive (R orRW), or other removable or fixed media drive might be provided.Accordingly, storage media 614 might include, for example, a hard disk,a floppy disk, magnetic tape, cartridge, optical disk, a CD or DVD, orother fixed or removable medium that is read by, written to or accessedby media drive 612. As these examples illustrate, the storage media 614can include a computer usable storage medium having stored thereincomputer software or data.

In alternative embodiments, information storage devices 610 mightinclude other similar instrumentalities for allowing computer programsor other instructions or data to be loaded into computing module 600.Such instrumentalities might include, for example, a fixed or removablestorage unit 622 and a storage unit interface 620. Examples of suchstorage units 622 and storage unit interfaces 620 can include a programcartridge and cartridge interface, a removable memory (for example, aflash memory or other removable memory module) and memory slot, a PCMCIAslot and card, and other fixed or removable storage units 622 andinterfaces 620 that allow software and data to be transferred from thestorage unit 622 to computing module 600.

Computing module 600 might also include a communications interface 624.Communications interface 624 might be used to allow software and data tobe transferred between computing module 600 and external devices.Examples of communications interface 624 might include a modem orsoftmodem, a network interface (such as an Ethernet, network interfacecard, WiMedia, IEEE 802.XX or other interface), a communications port(such as for example, a USB port, IR port, RS232 port Bluetooth®interface, or other port), or other communications interface. Softwareand data transferred via communications interface 624 might typically becarried on signals, which can be electronic, electromagnetic (whichincludes optical) or other signals capable of being exchanged by a givencommunications interface 624. These signals might be provided tocommunications interface 624 via a channel 628. This channel 628 mightcarry signals and might be implemented using a wired or wirelesscommunication medium. Some examples of a channel might include a phoneline, a cellular link, an RF link, an optical link, a network interface,a local or wide area network, and other wired or wireless communicationschannels.

In this document, the terms “computer program medium” and “computerusable medium” are used to generally refer to transitory ornon-transitory media such as, for example, memory 608, storage unitinterface 620, media 614, and channel 628. These and other various formsof computer program media or computer usable media may be involved incarrying one or more sequences of one or more instructions to aprocessing device for execution. Such instructions embodied on themedium, are generally referred to as “computer program code” or a“computer program product” (which may be grouped in the form of computerprograms or other groupings). When executed, such instructions mightenable the computing module 600 to perform features or functions of thepresent application as discussed herein.

Various embodiments have been described with reference to specificexemplary features thereof. It will, however, be evident that variousmodifications and changes may be made thereto without departing from thebroader spirit and scope of the various embodiments as set forth in theappended claims. The specification and figures are, accordingly, to beregarded in an illustrative rather than a restrictive sense.

Although described above in terms of various exemplary embodiments andimplementations, it should be understood that the various features,aspects and functionality described in one or more of the individualembodiments are not limited in their applicability to the particularembodiment with which they are described, but instead can be applied,alone or in various combinations, to one or more of the otherembodiments of the present application, whether or not such embodimentsare described and whether or not such features are presented as being apart of a described embodiment. Thus, the breadth and scope of thepresent application should not be limited by any of the above-describedexemplary embodiments.

Terms and phrases used in the present application, and variationsthereof, unless otherwise expressly stated, should be construed as openended as opposed to limiting. As examples of the foregoing: the term“including” should be read as meaning “including, without limitation” orthe like; the term “example” is used to provide exemplary instances ofthe item in discussion, not an exhaustive or limiting list thereof; theterms “a” or “an” should be read as meaning “at least one,” “one ormore” or the like; and adjectives such as “conventional,” “traditional,”“normal,” “standard,” “known” and terms of similar meaning should not beconstrued as limiting the item described to a given time period or to anitem available as of a given time, but instead should be read toencompass conventional, traditional, normal, or standard technologiesthat may be available or known now or at any time in the future.Likewise, where this document refers to technologies that would beapparent or known to one of ordinary skill in the art, such technologiesencompass those apparent or known to the skilled artisan now or at anytime in the future.

The presence of broadening words and phrases such as “one or more,” “atleast,” “but not limited to” or other like phrases in some instancesshall not be read to mean that the narrower case is intended or requiredin instances where such broadening phrases may be absent. The use of theterm “module” does not imply that the components or functionalitydescribed or claimed as part of the module are all configured in acommon package. Indeed, any or all of the various components of amodule, whether control logic or other components, can be combined in asingle package or separately maintained and can further be distributedin multiple groupings or packages or across multiple locations.

Additionally, the various embodiments set forth herein are described interms of exemplary block diagrams, flow charts and other illustrations.As will become apparent to one of ordinary skill in the art afterreading this document, the illustrated embodiments and their variousalternatives can be implemented without confinement to the illustratedexamples. For example, block diagrams and their accompanying descriptionshould not be construed as mandating a particular architecture orconfiguration.

What is claimed is:
 1. A non-transitory computer-readable medium havingcomputer executable program code embodied thereon, the computerexecutable program code configured to cause a computer system to:authorize payment for an e-commerce transaction; include a productidentifier in an e-commerce clearing record sent to a clearing systemthat includes e-commerce information associated with the e-commercetransaction corresponding to an approved authorization record; validatethe e-commerce clearing record and authenticate the product identifier;and provide reconciliation based on the validated e-commerce clearingrecord and the authenticated product identifier.
 2. The non-transitorycomputer-readable medium of claim 1, wherein the computer executableprogram code configured to cause the computer system to validate thee-commerce clearing record and authenticate the product identifierfurther causes the computer system to parse the e-commerce clearingrecord to obtain the product identifier at a clearing system of apayment network.
 3. The non-transitory computer-readable medium of claim2, wherein the computer executable program code configured to cause thecomputer system to validate the e-commerce clearing record andauthenticate the product identifier further causes the computer systemto transmit the product identifier to a data repository to allow for acomparison between the product identifier and existing productidentifiers maintained within the data repository to ascertain whether amatch between the product identifier and one of the existing productidentifiers exists.
 4. The non-transitory computer-readable medium ofclaim 3, wherein the computer executable program code is configured tofurther cause the computer system to transmit a clearing message.
 5. Thenon-transitory computer-readable medium of claim 4, wherein the computerexecutable program code is configured to further cause the computersystem to initiate payment settlement subsequent to transmission of theclearing message.
 6. The non-transitory computer-readable medium ofclaim 4, wherein the computer executable program code configured tocause the computer system to validate the e-commerce clearing record andauthenticate the product identifier further causes the computer systemto withhold transmission of the clearing message upon a determinationthat the product identifier cannot be authenticated.
 7. Thenon-transitory computer-readable medium of claim 6, wherein the computerexecutable program code is configured to further cause the computersystem to send at least one notification to at least one of amanufacturer a product associated with the product identifier, adistributor of the product associated with the product identifier, and amerchant through which the e-commerce transaction was initiatedindicating the determination that the product identifier cannot beauthenticated.
 8. A payment network, comprising: at least one server;and at least one memory module storing computer program code, whereinthe at least one memory module and stored computer program code areconfigured to, with the at least one processor, cause the server to:parse a payment transaction message associated with a paymenttransaction to obtain a product identifier associated with a product tobe purchased; transmit the product identifier to a verification entityfor verification that the product is authentic; upon a determinationthat the product is authentic transmit a payment transaction responsemessage approving the payment transaction; and upon a determination thatthe product is counterfeit, transmit a payment transaction responsemessage declining the payment transaction.
 9. The payment network ofclaim 8, wherein the product identifier is received via one of a mobiledevice payment application or a merchant point-of-sale (POS) terminal,and wherein the payment transaction message comprises an authorizationrequest message.
 10. The payment network of claim 8, further comprisinga clearing system configured to process clearing and settlementassociated with the payment transaction subsequent to authorization ofthe payment transaction.
 11. The payment network of claim 10, where theclearing system withholds transmission of a clearing message prior tosettlement of the payment transaction upon the determination that theproduct is counterfeit.